Centralized databases are becoming increasingly popular for storing electronic files or “database assets.” Most databases are operated under a client/server computer network model. In a client/server network, a client computer requests information (e.g., makes a request for files or database assets, etc.) from a server computer. In response to the request, the server computer searches the database for the requested information, retrieves the information, and communicates the information to the requesting client computer.
Having a general repository of information such as a database is advantageous because it allows multiple users to access the same file from various client computers, thereby allowing, for example, employees from disparate departments to work together on the same project, thus promoting efficiency and teamwork. Furthermore, because employees can access the database from remote computers via a network (e.g., LAN, Internet, etc.), the employee can access and work on files from home or while “on the road.” Thus, databases help support employee mobility and even the most mobile employees can work with database assets so long as the employee can establish a network connection to a database server (e.g., the computer responsible for handling database requests).
Additionally, databases free organizations from relying on individual users to store files on local machines. Using a centralized database to store files can decrease the likelihood that a file will be lost or corrupted if an employee misplaces or damages his/her computer. Yet another advantage provided by centralized databases is that an organization can control user access to particular database assets. Through authentication and authorization (validation) processes, such as requiring user names and/or passwords, an organization can govern which employees can work with particular files. This can help in controlling of work product and in ensuring quality control.
Because database assets are usually transported over a relatively slow network connection, a cache at the user's computer can be used to increase the speed with which files can be accessed and modified. A cache typically stores a local copy of a database asset on the user's computer. Thus a user can access and modify a local copy of a file, which is generally much faster than accessing a file directly over a network. When a user makes a change to the local or “cached” file copy, the change can, as will be described below, be synchronized with the database from which the file was originally retrieved.
Despite the many advantages provided by databases, databases also present many challenges to organizations. Typically, an organization's database(s) include a myriad of different database asset types. For example, a corporation's database might include Microsoft™ Word™ files, Microsoft™ Excel™ files, WordPerfect™ files, text files, graphics files (e.g., .jpg, .tif, or .gif), html files, AutoCAD™ files, etc. In addition to storing multiple types of database assets, there may also be a number of different users trying to access the same files.
Adding to the complexity of database management, various users of database assets may prefer to use different tools (e.g., they will have a “tool of choice)” to modify different types of database assets. Thus, for example, one user may prefer to use Microsoft™ Word™ to edit word processing documents while another user may prefer a different text editor. Therefore, in managing a network incorporating a database, an organization must be able to reconcile the multifarious subjective user preferences.
Several systems have been developed in an attempt to meet the challenges presented by database management. One current system requires that users employ custom-designed tools in order to edit the assets in a database. While the custom-designed tools typically reduce latency by automatically saving changes or modifications to the database, these systems are unattractive because they do not allow a user to seamlessly employ his/her tool of choice. Instead, the user must utilize a tool provided by the database vendor or an external editor that is typically cumbersome to use. Because he/she may not be familiar or efficient with the tool, the user may require extra training and, consequently, this can result in extra expense to the employer or other organization.
A second option that is currently available allows a user to utilize standard software tools (e.g., Microsoft™ Word™) to access and modify database assets, but requires a second program (a “synchronization program”) on the client machine to synchronize any modifications that a user makes on his/her client machine with the database. These systems, also have several shortcomings. Primarily, synchronization programs are typically designed to run with only one software tool (e.g., they act as a plug-in to an existing software application) or, if designed to run with multiple programs, they require significant amounts of additional coding. Thus, a user will be able to use only the tools for which the organization has a synchronization program in place. Therefore, a user's choice in software is severely limited by the presence or absence of a synchronization program. Furthermore, these prior art systems typically require that the user take extra steps in saving data to the database. When a user saves a file on his/her local (e.g., client) machine, he/she typically must also save the file in the synchronization program in order to have the file saved to the database. While it may only take an additional few seconds to save a file to the database using the synchronization program (though it can take significantly longer, particularly to save large files to a remote database), over the course of many saves this can lead to significant losses in time and productivity. These systems are also deficient because they can lead to significant latency problems. If a user forgets to perform the extra step of saving a file to the database using the synchronization program, any modifications that the user saved using a local program or tool will only be saved locally and will not be reflected on the database until the user synchronizes the local file with the database. Thus, if a user forgets to save a file to the database using the synchronization program, the database will not contain the latest version of a file for a potentially long period of time. Consequently, if another user access the file from the database before synchronization occurs, he or she will not receive up-to-date information.
Yet another existing system for accessing and modifying database assets that has been developed is an operating system-level implementation that creates a file system on a local machine (e.g., a user's computer or client computer), that allows the user to view database assets as if the assets were locally situated. In this system, the user sees the database reflected as an additional virtual local storage device (e.g., an “E” drive). Database assets are depicted as files on the file system. When a user selects the database asset that he/she wants to edit (e.g., by double clicking on the asset), the database asset can be retrieved from the database and can be opened locally with whichever program is associated with that particular type of asset (e.g., Adobe®) PhotoShop could open .jpg files). This system presents shortcomings, however, because it requires additional programming at the operating system “driver” level. Any defect or error in the program while the program is running can cause the local user's machine to cease functioning or “crash” until the operating system is reinitialized (e.g., until the client computer is rebooted), significantly reducing user productivity, and leading to loss of data.